A conventional processor executing real-time operating systems commonly executes several software programs in a time-sliced fashion. The software programs therefore compete with each other for use of system resources. Resource contentions are commonly prevented by employing semaphores between the software tasks. Software-based semaphores are created within the software by progressing through a section of “critical” code where task switching is prevented and memory (where a software semaphore would be stored) accessed while all task switching/interrupt servicing is suspended. Executing the “critical” code can involve servicing exceptions that are relatively time consuming and processor intensive.
The resource contention problem grows significantly when multiple processors are used in the system implementing a unified memory mapping. Each processor commonly requires access to shared resources such as shared regions of memory for inter-processor command passing and shared use of system peripherals such as a Data Move Engine with Direct Memory Access capabilities. Since each task and processor will function independently, a system of semaphores is required to ensure that operations are sequenced correctly (i.e., while a resource is in use, an active semaphore ensures that no other task uses the resource).
Multi-processor software semaphore implementations commonly require some form of communication between processors to lock out all processors from the shared resource while a semaphore is written. The inter-processor communication in itself requires semaphores to control the shared memory necessary for command passing and so the system becomes unstable. Running the critical code to set the semaphores conventionally involves locking out all system interrupts and so can cause timing issues with regard to true real-time operation. A resource shared between processors requires that the sharing processors be locked within a safe state. In other words, the sharing processors must not switch tasks or service interrupts.